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(54) Method for securing data relating to users of a public-key infrastructure 



(57) The inventive-method allows to secure data re- 
lating to users of a public key infrastructure who may 
present certificates (11) at an institution (30) in order to 
initiate transactions. For this purposes the institution 
(30) uses and securely stores a secret key or a key pair 
which is designed for encrypting and decrypting data. 
Based on an agreement between a certificate holder 
and the institution (30), corresponding relational data 
are generated. Then said relational data are encrypted 
with the institution's (30) secret key or the first key of 
said key pair. Subsequently the encrypted relational da- 



ta are integrated into the certificate (1 1 ) which preferably 
adheres to ITU recommendation X.509 version 3. At a 
later stage, wheneverthe certificate holder contacts the 
institution (30) in order to initiate a transaction based on 
said agreement between the certificate holder and the 
institution (30), encrypted relational data contained in 
the certificate (11) is decrypted by means of the secret 
key or the second key of said key pair of the institution 
(30). Based on the decrypted relational data, data stored 
in a directory (33) of the institution (30) can be verified 
and the requested transaction be performed. 
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Description 

[0001] The present invention relates to a method for 
securing data relating to users of a public key infrastruc- 
ture according to claim 1. 

[0002] The present invention relates in particular to a 
method for securing data which are based on relations 
between certificate holders and institutions or closed us- 
er groups. 

[0003] More particularly the present invention relates 
to a method for securing relational data, based on which, 
for example, business transactions are performed or ac- 
cess to a system may be granted by using an open, pub- 
lic certificate while privacy of the relations between cer- 
tificate holders and institutions can be maintained. 

BACKGROUND OF THE INVENTION 

[0004] The emergence of the World Wide Web access 
to the Internet has been accompanied by recent focus 
on financial transaction vulnerabilities, crypto system 
weaknesses and privacy issues. Fortunately, techno- 
logical developments also made a variety of controls 
available for computer security including tokens, bio- 
metric verifiers, encryption, authentication and digital 
signature techniques using preferably asymmetrical 
public-key approaches (see [1], Richard C. Dorf, THE 
ELECTRICAL ENGINEERING HANDBOOK, 2nd Edi- 
tion, CRC-Press, Boca Raton 1997, chapter 97, pages 
2221-2234 and [7], A. Menezes,- P. van Oorschot, S. 
Vanstone, HANDBOOK OF.APPLIED CRYPTOGRA- 
PHY, CRC-Press, Boca Raton 1997, chapter 1). 
[0005] The basic objectives of encryption are secrecy, 
authentication (assurance of sender identity to recipi- 
ent), and digital signatures (authentication plus assur- 
ance to sender and third parties that the signature had 
not been created by the recipient). This is normally re- 
ferred to as non-repudiation, with further variants such 
as non-repudiation of origin, non-repudiation of sending 
and so on. Of further importance is integrity which 
means preventing interference in the information con- 
veying process. 

[0006] Almost all cryptosystems involve publicly 
known transformations of information, based on one or 
more keys, at least one of which is kept secret. The pub- 
lic-key cryptosystem disclosed 1976 by Diffie and Hell- 
man is based on two keys, a private-key and a public- 
key, owned by users of this system. 
[0007] As described in [2], U.S. Patent document No. 
4,405,829 for the RSA cryptosystem explained below, 
the public-key cryptosystem provides enciphered com- 
munication between arbitrary pairs of people, without 
the necessity of their agreeing on an enciphering key 
beforehand. The Diffie and Hellman system also pro- 
vides a way of creating for a digitised document a rec- 
ognizable, unforgeable, document-dependent, digitised 
signature whose authenticity the signer cannot later de- 
ny. 



[0008] The RSA cryptosystem (named after R.L. 
Rivest, A. Shamir and L.M. Adleman which in [2] are 
mentioned as inventors) is the most widely used public- 
key cryptosystem. RSA is a commutative transforma- 
tion, which allows the private-key and the corresponding 
public-key to be used interchangeably as encryption 
and decryption keys, thus providing secrecy and au- 
thenticity on a secure channel between two parties A 
and B with no need for additional keys (see [1], pages 
2225-2226). 

[0009] Since, given only one key of an asymmetric 
key pair, it is practically infeasible to determine the other 
key, an owner A of a key pair may publish his public-key. 
so that anyone can use this public-key to encrypt a mes- 
sage that only A can decipher with his private-key. 
[0010] As described in [3], Marc Branchaud, A SUR- 
VEY OF PUBLIC-KEY INFRASTRUCTURES, Depart- 
ment of Computer Science, Mc Gill University, Montreal 
1997, page 5, computing with public-key ciphers takes 
much longer than encoding the same message with a 
secret-key system. This has led to the practice of en- 
crypting messages with a secret-key system such as 
DES and then encoding the secret-key with a public-key 
system such as RSA. In this case the public-key system 
securely transports the secret-key. In case that a mes- 
sage is sent secretly from A to B then, besides a secret- 
key, which is used optionally, only the key pair of B is 
used. 

[0011] The described public-key system also allows 
owner A to sign a message to be sent to B with a digital 
signature. In this case the key pair of A is used. A en- 
crypts the message or a corresponding hash of the mes- 
sage with his private-key which, on the other side of the 
transmission channel can be decrypted by B using A's 
public key. One key paircan therefore be used to receive 
an encrypted message orto send a digitally signed mes- 
sage. 

[0012] B (and any third parties), who can decrypt with 
A's public-key a message signed by A, can therefore 
trust that A has signed the message as far as Bean trust 
that the selected public-key truly belongs to A. 
[0013] In ordertoensurethatpublic-keyscan system- 
atically be published and truly relate to the persons A, 
B, ... indicated by attached public-key values, registra- 
tion- and certification authorities (RA, CA) have been in- 
troduced to certify the relationship between a given key 
and a claimed identity. 

[0014] According to [31, page 10 a public-key infra- 
structure, in its most simple form, is a system for pub- 
lishing public-key values used in public-key cryptogra- 
phy. There are basic operations, namely registration, 
certification and validation, which are common to all 
public-key infrastructures. 

[0015] Certification is the means by which registered 
public-key values, and information pertaining to those 
values, are published. A basic certificate therefore con- 
tains at least the public-key of the concerned subject, 
subject identification information, and identification in- 
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formation of the certifying authority. 
[0016] The certificate is signed by the certifying au- 
thority with the certifying authority's private-key and can 
be validated with the publicly known public-key of the 
certifying authority. In other words a certificate is there- 
fore an encyrypted message issued by the certifying au- 
thority declaring that the therein contained public-key re- 
lates to the enclosed subject identification information. 
[0017] As described in [3], pages 19-21 , authentica- 
tion is a process provided by a public-key infrastructure. 
When a certifying authority certifies an entity and a user 
then validates that certification, the entity is said to have 
been authenticated. 

[0018] The degree to which a user can trust the cer- 
tificate's information and it's validity is a measure of the 
strength of the authentication. 

[0019] [4], U.S. Patent document NO. 6,202,151 B1 
describes a biometric certification system and method 
which implement an end-to-end security mechanism 
binding the biometric identification of consumers with 
digital certificates. 

[0020] Users can also be authenticated through 
something possessed such as a token or a smart card. 
Tokens are, as described in [1 ], pages 2228-2229, hand- 
carried devices that are normally intended to increase 
password security by assuring that passwords are used 
only once, thereby reducing the vulnerability to pass- 
word compromise. Tokens may contain internally an al- 
gorithm; which either works in synchronisation with an 
identical algorithm in a host computer or which trans- 
form an input derived from a computer prompt into a 
password that; matches the computer-transformed re- 
sult. In a public-key infrastructure a token containing a 
private-key may used to sign a message as described 
above. 

[0021] The degree of authentication of a user by 
means of a token is however in many cases not strong 
enough. A man, to which the token had been assigned, 
may, rightfully or not, deny at a later stage that the token 
actually belongs to him, 

[0022] In order to significantly increase the degree of 
authentication, in the not yet published European Patent 
Application No. 01 81 051 3.0 it is proposed to register us- 
ers by means of a token or an other secure device at an 
authority, preferably the registration authority of a pub- 
lic-key infrastructure based on credentials, including 
signed biometric data presented to said authority. 
[0023] The biometric data are signed by means of a 
private key issued individually by the registration author- 
ity automatically for each token. In addition to signing 
the biometric data with the private key of the registration 
authority the data can further be signed with the user's 
private key contained in the token. 
[0024] After registration the token is a secure element 
of the public-key infrastructure allowing to encrypt mes- 
sages and securely sign messages, with digital signa- 
tures, on which a third party can rely on. 
[0025] It therefore seems that the basic objectives of 



encryption mentioned before, secrecy, authentication, 
digital signatures and integrity are achieved by applying 
the technology described above. 
[0026] However the use of public key infrastructures 

s still involves risks which are described in [6], Carl Ellison 
and Bruce Sen neier, Ten Risks of PKI: What You're not 
Being Told about Public Key Infrastructure, Computer 
Security Journal, Volume XVI, Number 1 , 2000. 
[0027] For an institution such as bank institute a first 

10 risk i.e. question mentioned in [6] is, whom the institution 
can trust. Further risks or questions are derivatives of 
this question asking, whether the institute can trust the 
certification authority or rely on certification processes. 
[0028] Important is the question, whether the authen- 

15 ticated person, for example OLIVIER HOLDER, is actu- 
ally the person who is presenting the certificate. With 
the incorporation of the user's biometric data into the 
certification process it can be trusted that OLIVIER 
HOLDER is correctly authenticated. However the ques- 

20 tion remains whether OLIVIER HOLDER, with whom the 
institution is connected over a communication channel, 
is actually the man with whom the institution formerly 
communicated or whether it is a different person with 
the same name. In this respect in [6] also the security 

25 of the verifying computer is discussed. For example an 
attacker could add his own public key to the list of public 
keys maintained in institution, so that he could issue his 
own certificates, for example issued on the name of OL- 
IVIER HOLDER, which would be treated exactly like le- 

30 gitimate certificates. 

[0029] In view of relating a calling client, such as OL- 
IVIER HOLDER, to the correct one among one or more 
clients with the same name, an institution normally uses 
a mapping list (see figure 1 , 32), which maps data re- 

35 trieved from a certificate to records of a customer data- 
base such as the directory 33 shown in figure 1 . Besides 
the question whether the certificate from which data is 
used for mapping purposes, a new question arises, 
which has not been addressed in [6]. The question is, 

40 can the institution trust itself? For the bookkeeper of a 
bank institute it makes little difference whether a person 
internal or external to the institution is responsible for an 
illegal transfer of a million dollars. Therefore in case that 
the institution is perfectly shielded against external at- 

45 tackers it is still possible that the mapping list or the cus- 
tomer database has been manipulated by an internal at- 
tacker. 

[0030] It would therefore be desirable to reduce the 
described risks thus improving public-key infrastruc- 
50 tures. 

[0031] It would be desirable in particular to improve 
overall system reliability, in particular authentication and 
data integrity. 

[0032] More particularly it would be desirable to pro- 
55 vide a method for securing relational data based on 
which business transactions are performed by an insti- 
tution which acts according to instructions received by 
said certificate holder. In fact it would be desirable that 
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the institution be removed from as many issues as pos- 
sible concerning liability within an open, public key in- 
frastructure, so that the institution is only responsible for 
the internal processing and security of any data belong- 
ing or related to its customer and does not need to rely 
on a trusted third parly. 

[0033] It would further be desirable to achieve the de- 
scribed objects with practically no significant invest- 
ments and efforts by the institution and the certificate 
holders. 

SUMMARY OF THE INVENTION 

[0034] The above and other objects of the present in- 
vention are achieved by a method according to claim 1 . 
[0035] The inventive method allows the securing of 
data related to users of a public key infrastructure, who 
may present certificates at an institution in order to ini- 
tiate transactions. For this purposes the institution pref- 
erably uses and securely stores a secret key or a key 
pair which is designed for encrypting and decrypting da- 
■ ta. 

[0036] Based on a request of a client, who is the hold- 
er of a certificate, an institution may allow the certificate 
holder to base future transactions or system access on 
his certificate. According to security regulations imple- 
mented, the institution will preferably verify that the per- 
son who is presenting the certificate is the actual owner 
for whom the certificate had been issued. The institution 
will further verify whether the certificate holder relates 
to a registered user or contract holder with the institu- 
tion, and will demand corresponding proof of this rela- 
tionship. 

[0037] Based on an agreement or a contract closed 
between a certificate holder and the institution, corre- 
sponding relational data are generated. Then said rela- 
tional data are encrypted preferably with the institution's 
first key of an asymmetric key pair such as a private/ 
public key pair. 

[0038] Subsequently the encrypted relational data are 
integrated into the certificate, which preferably adheres 
to ITU recommendation X.509 version 3. The relational 
data could be included in the certificate as a non-stand- 
ard certificate extension. 

[01)39] At a later stage, wheneverthe certificate holder 

contacts the institution in order to initiate a transaction 
based on said agreement between the certificate holder 
and the institution, encrypted relational data contained 
in the certificate is decrypted by means of the secret key 
or the second key of said key pair of the institution. 
[0040] Sincethecertificates.intowhichrelationaldata 
are integrated, are elements of the public key infrastruc- 
ture, other processes provided in this infrastructure are 
also performed whenever a certificate is presented. In 
case that an authentication of a certificate holder fails, 
for example due to expiration of the certificate, then the 
inventive method would not be applied. 
[0041] The inventive method therefore allows institu- 



tions to integrate relational data into the certificate of a 
certificate holder, in the form of specific attributes de- 
fined and recognized by that institution. These institu- 
tional attributes are encrypted by the institution and can . 

s only be decrypted by the institution again. 

[0042] The encryption and decryption of relational da- 
ta can be performed by means of a single secret key 
(see [3], page 4) since the encrypted relational data cor- 
responds to a message which is written and read by the 

io same party i.e. the institution only. A transfer of the se- 
cret key across the network from a sender to receiver is 
therefore not required. 

[0043] However in orderto increase security internally 
in the institution a key pair could be used with one key 

15 held in a registration department, where relational data 
are encrypted, and the other key held securely stored 
in another department, for example where transactions 
are handled. Said keys correspond to a private key and. 
a public key of the public key infrastructure although 

20 preferably both of these keys are not published. 

[0044] A holder of a certificate opens for example an 
account at an institution, for example a bank, which, 
based on an agreement of terms regarding said account 
generates relational data which then is integrated in en- 

25 crypted form into the certificate. 

[0045] This enables the institution to identify and au- 
thenticate a certificate holder in a much stronger fashion 
than would be possible without the additional institution- 
al attributes. In case that the certificate passes standard 

so authentication, it is established that the certificate be- 
longs for example to an OLIVIER HOLDER. Decrypting 
the encrypted relational data contained in the certificate 
confirms the identity of OLIVIER HOLDER, and indi- 
cates what relations exist between OLIVIER HOLDER 

35 and the institution. In case thai several persons with the 
name .HOLDER are registered at the institution, it is si- 
multaneously established which one of these persons 
is concerned. 

[0046] In order to prevent transfer of encrypted rela- 
te tional data i.e. of an institutional attribute from an original 
certificate to a certificate used by an attacker, said en- 
crypted relational data are strongly linked to the original 
certificate by means of integrating certificate specific da- 
ta Into the institutional attribute, so that manipulated cer- 
45 tificates, which contain transferred institutional at- 
tributes, can be identified. . 

[0047] The risks described in [6] are therefore signif- 
icantly reduced by applying the inventive method. 
[0048] In view of [6], Risk#1 ("Who do we trust, and 

50 for what?"), trust received by the elements of the public 
key infrastructure are combined by using the inventive 
method with the trust the institution has in itself. It is im- 
portant to note that the additional link in the security 
chain is not linked serially but in parallel to existing links 

55 of the chain. In case that an element of the public key 
infrastructure fails then the security chain still holds by 
means of the inventive measures. 
[0049] In case that the institution uses a pair of keys, 
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which are securely stored in separate departments then 
the trust in the institution itself can further be increased. 
[0050] In view of [6], Risk#4 ("Which JOHN ROBIN- 
SON is he?"), it has been explained that among several 
persons bearing the same name (e.g. OLIVIER HOLD- s 
ER i.e. JOHN ROBINSON) the correct person can easily 
be identified by means of the decrypted relational data, 
which comprise for example the client number and fur- 
ther details of the agreement between the institution and 
the certificate holder or a further institution the certificate »o 
holder is working for. By means of the inventive method 
the institution can therefore reliably answer the extend- 
ed question "Which OLIVIER HOLDER is he and what 
is our relation to this OLIVIER HOLDER?". 
[0051] Since the relational data are encrypted in the « 
certificate a third party or the certificate holder will not 
have access to this relational data. The third party will 
not even have access to one of the keys of the institute's 
key pair. A certificate holder can therefore have institu- 
tional attributes of different institutions integrated in his 20 
certificate and still maintain secrecy, since an institution 
can decrypt relational data only with the corresponding 
key. 

[0052] The certificate remains therefore open to the 
public except for encrypted relational data integrated 25 
therein. 

[0053] In a preferred embodiment of the invention de- 
crypted relational data is used to verify data of a calling 
client which data is stored in a directory of the institution. 
A mapping list is no longer required since data required 30 
e.g. for mapping the name of a client to a client number 
is already contained in the relational data i.e. the insti- 
tutional attribute. The system on the institute's side is 
therefore simplified. A manipulation of the directory can 
easily be detected during the described verification 35 
process, so that integrity of data at least in th e used parts 
of the directory is always established. 
[0054] The inventive method therefore allows to sig- 
nificantly improve overall system reliability, in particular 
authentication and data integrity, by selectively simpli- 40 
tying the open cryptographic communications system 
through selective integration of closed modules. 
[0055] In a different embodiment of the invention an 
institution, such as a governmental authority, may also 
integrate relational data into a certificate, which is based 45 
on approved information. The institution confirms cor- 
rectness of this information by signing the unencrypted 
relational data with the private key of the institution. 
[0056] Any third party, particularly the attribute inte- 
grating certification authority, can verify said signature so 
contained in the certificate by means of the published 
public key of the institution whenever the confirmed in- 
formation needs to be proven. 

[0057] In a preferred embodiment the information 
may concern the fact that the certificate holder possess- 55 
es additional certificates. The institutionor an attribute 
integrating certification authority may verify and confirm 
correctness of the additional certificates by generating 



and signing corresponding unencrypted relational data 
with the private key of the institution. 
[0058] In order to integrate the encrypted or signed 
relational data in the certificate said relational data is 
sent to the concerned authority of the public key infra- 
structure which adds the received encrypted or signed 
relational data and reissues the certificate. 
[0059] The process of generating, encrypting, trans- 
mitting and integrating new relational data into a certif- 
icate as well as reissuing and sending the enhanced cer- 
tificate to the institution and to the certificate holder can 
take place during the same session established be- 
tween the certificate holder and the institution. The up- 
date of the certificate can therefore automatically be ex- 
ecuted in a short time period without any noticeable ef- 
fort by the concerned parties, the insignificant efforts 
required for updating certificates stand however in rela- 
tion to large efforts required instead for maintaining in- 
tegrity of data of the institution's databases. 
[0060] The certificate is preferably stored in a token 
which is carried by the certificate holder. In case that the 
token comprises a biometric input device it could be as- 
sured that only the certificate holder could use the token . 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0061] Some of the objects and advantages of the 
present invention have been stated, others will appear 
when the following description is considered together 
with the accompanying drawings, in which: 

Figure 1 shows a known public key infrastructure op- 
erating with conventional certificates; 

Figure 2 shows a public key infrastructure operating 
according to the inventive method and 

Figure 3 shows a certificate extended with attributes. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0062] Figure 1 shows a known public key infrastruc- 
ture operating with conventional certificates. A person, 
e.g. OLIVIER HOLDER, may apply at an authority 100 
of the public key infrastructure for a certificate 11 . The 
authority 1 00, which over the Internet 200 is connected 
to terminals 20, 30 of users of the public key infrastruc- 
ture, normally consists of a registration authority 1 01 , a 
certification authority 102, a key and certificate manage- 
ment unit 1 03 and a database 1 04 containing the direc- 
tory of the public key infrastructure. The applicant, OL- 
IVIER HOLDER, may use a soft or a hard token 10a, 
10b, 10c. 

[0063] Credentials submitted to the registration au- 
thority 1 01 preferably comprise biometric data which al- 
low strong authentication of an applicant. An applicant 
therefore preferably uses a token 10a which allows to 
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read biometric data by means of a biometric input device 
1 . As described in the European Patent Application No. 
01 81 051 3.0 biometric data may be read during registra- 
tion only or also thereafter for each transaction initiated 
by the certificate holder based on the certificate. 
[0064] The issued certificate 11, which comprises a 
public key 12 can then be used as described above or 
in [3], pages 5-12. OLIVIER HOLDER may for example 
present his certificate 11 on-line over the Internet 200 at 
an institution 30, for example a bank institute in order to 
initiate a transaction such as a transfer of money from 
his account to an account of third parties. 
[0065] In the known infrastructure the institution 30 
needs to trust the certificate 11 i.e. the certification au- 
thority 1 02 in order to authenticate OLIVIER HOLDER, 
the holder of the transmitted certificate 1 1 . By means of 
a map or a mapping list 32 the institute relates the au- 
thenticated person to a record stored in a directory 33, 
which contains the data of the client, OLIVIER HOLD- 
ER. In case that the directory 33 contains data of differ- 
ent persons with the name OLIVIER HOLDER then the 
serial number of the certificates 1 1 may be used for the 
mapping process. 

[0066] The risks involved in this procedures have 
been described above. Institutions 30 may distrust ex- 
ternal authorities, such as the certification authority 1 02, 
particularly for transactions concerning large amounts 
of money. In addition institutions 30 should be aware of 
risks within their own premises. As detailed above at- 
tackers could intrude the computer systems of the insti- 
tutions 30 and manipulate the mapping list 32 and/or the 
directory 33. 

[0067] Figure 2 shows a public key infrastructure op- 
erating according to the inventive method. In the given 
example the certificate holder, OLIVER HOLDER, uses 
a token 1 0a comprising a biometric input device. Other 
means, such as a soft token (see figure 1, 10c), for stor- 
ing the certificate 11 could be used as well. 
[0068] As shown in figure 2 the certificate held by OL- 
IVIER HOLDER is an extendable certificate 11 such as 
a certificate specified according to ITU recommendation 
X.509 version 3 which is described in [3], pages 40-42. 
[0069] According to the present invention an institu- 
tion 30 may allow the certificate holder to base future 
transactions or system access on his certificate 11. 
Based on security regulations implemented the institu- 
tion 30 will preferably verify that the person who is pre- 
senting the certificate 11 is the actual owner for whom 
the certificate 11 had been issued. The institution 30 will 
further verify whether the certificate holder relates to a 
registered user or contract and will demand correspond- 
ing proof. This initial verification can take place in a know 
manner, e.g. by transferring passwords orkeywords tak- 
en from a list over a secure channel. 
[0070] According to the present invention data relat- 
ing to the client of the institution 30 are securely stored 
in the certificate 11 thus avoiding the use of a mapping 
list. 



[0071] For this purposes the institution preferably us- 
es and securely stores a secret key or a key pair which 
is designed for encrypting and decrypting data. Based 
on an agreement or a contract closed between the hold- 
s er of the certificate 11 and the institution 30, correspond- 
ing relational data are generated. 
[0072] Then said relational data are encrypted with 
the institution's secret key or the first key 35 of said key 
pair. Subsequently the encrypted relational data are in- 
fo tegrated into the certificate 1 1 . 

[0073] In order to integrate the encrypted relational 
data into the certificate 1 1 said encrypted relational data 
is sent to the authority 100 of the public key infrastruc- 
ture which adds the received data as an institutional at- 
15 tribute and reissues the certificate 1 1 . Subsequently the 
certificate is transferred to the certificate holder and 
preferably as well to the institution 30. 
[0074] The process of generating, encrypting and in- 
tegrating the relational data as well as reissuing the cer- 
20 tificate 11 can performed within minutes during a ses- 
sion between a calling certificate holder and the institu- 
tion 30. 

[0075] At a later stage, wheneverthe certificate holder 
contacts the institution in order to initiate a transaction 
25 based on an agreement between the certificate holder 
and the institution 30, encrypted relational data is read 
from the certificate 1 1 . decrypted by means of the secret 
key orthe second key 36 of said key pair of the institution 
30. 

so [0076] This enables the institution to identify and au- 
thenticate a certificate holder much stronger. In case 
that the certificate passes standard authentication, it is 
established that the certificate belongs for example to a 
OLIVIER HOLDER. Decrypting the encrypted relational 

35 data contained in the certificate confirms the identity of 
OLIVIER HOLDER, and indicates what relations exist 
between OLIVIER HOLDER and the institution. In case 
that several persons with the name HOLDER are regis- 
tered at the institution, it is simultaneously established 

40 which one of these persons is concerned. 

[0077] In a further step the decrypted relational data 
is preferably used to verify data stored in a directory 33 
of the institution 30. A mapping list is no longer required 
since data required for mapping the name of a client to 

45 a client number is already contained in the relational da- 
ta i.e. the institutional attribute. 
[0078] The encryption and decryption of relational da- 
ta by the institution 30 can be performed by means of a 
single secret key (see [3], page 4) since the encrypted 

so relational data corresponds to a message which is writ- 
ten and read by the same party i.e. the institution 30 only 
and a transfer of the secret key across the network from 
a sender to receiver therefore is not required. 
[0079] In order to increase security internally in the 

55 institution an asymmetric key pair such as a private/pub- 
lic key pair is preferably used with the first key, which for 
example corresponds to a private key held in a registra- 
tion department, where relational data are encrypted, 
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and the second key, which corresponds to a "public" key, 
held securely stored in another department, for example 
where transactions are handled. 
[0080] Although the term public key is used for the 
second key, this second key is preferably securely s 
stored in a department of the institution. 
[0081] Since the relational data are contained in en- 
crypted form in the certificate a third party or the certif- 
icate holder will not have access to this relational data. 
A third parry or the certificate holder will not even have 10 
access to one of the keys of the institute's key pair. A 
certificate holder can therefore have institutional at- 
tributes of different institutions integrated in his certifi- 
cate and still maintain secrecy, since an institution can 
decrypt relational data only with the corresponding key. 15 
[0082] in order to prevent transfer of encrypted rela- 
tional data i.e. of an institutional attribute from an original 
certificate to a certificate used by an attacker, said en- 
crypted relational data are preferably strongly linked to 
the original certificate by means of integrating certificate 20 
specific data into the institutional attribute, so that ma- 
nipulated certificates, which contain transferred institu- 
tional attributes, can be identified. 
[0083] For this purpose the encoded relational data 
are preferably combined with a data segment i.e. a cer- 25 
tificate identifier, which is suitable to identify the certifi- 
cate. 

[0084] As shown in Figure 3 preferably the hash of the 
certificate body, which has been signed by the certifica- 
tion authority 102, is used as certificate identifier. In or- so 
der to link the certificate identifier to the encoded rela- 
tional data, a' hash of the combination of the encoded 
relational data and the certificate identifier is built, 
signed by the Institution and added to the institutional 
attribute. When receiving the certificate at a later stage 35 
the institution can easily verify that the certificate iden- 
tifier belongs on the one hand to the encrypted relational 
data and on the other hand to the presented certificate 
thus closing the link between the institutional attribute 
and the presented certificate. 40 
[0085] Figure 3 shows the certificate 11 extended with 
three attributes 

1 ) the hash of the certificate body signed by the cer- 
tification authority 102, 45 

2) a first institutional attribute comprising relational 
data encrypted by the institution 30, the hash of the 
certificate body signed by the certification authority 

1 02 and the hash of the combination of the encrypt- so 
ed relational data and the hash of the certificate 
body, said hash of this combination signed by the 
institution 30 and 

3) a second institutional attribute comprising rela- 55 
tional data encrypted by the institution 30 and the 
hash of the combination of the encrypted relational 
data and the hash of the certificate body, said hash 



of this combination signed by the institution 30. 

[0086] In the second institutional attribute the hash of 
the certificate body is not included since this hash is in- 
cluded in the certificate 11 as attribute. 
[0087] In a different embodiment of the invention an 
institution 30, such as a governmental authority, may al- 
so integrate relational data into a certificate 1 1 , which is 
based on information the institution has approved. The 
institution 30 confirms correctness of this information by 
signing the unencrypted relational data with the private 
key of the institution 30. 

[0088] Any third party can verify said signature con- 
tained in the certificate by means of the corresponding 
published public key of the institution 30 whenever the 
confirmed information needs to be proven. In this case 
the institution 30 preferably uses a different key set 
namely the key set for which a certificate was issued 
and published by an authority 100 of the public key in- 
frastructure. 

[0089] In a preferred embodiment the information 
may concern the fact that the certificate holder possess- 
es additional certificates. The institution 30 which can 
be the certificate issuing certification authority itself, 
may verify and confirm correctness of the additional cer- 
tificates by signing the resulting unencrypted relational 
data with the private key. In orderto integrate the signed 
relational data in the certificate said relational data is 
sent to the concerned authority of the public key infra- 
structure which adds the received data and reissues the 
certificate as described above. 
[0090] The certificate 1 1 incorporates in this case two 
or more certificates which at least for the institution 30 
but also for third parties may considerably raise the trust 
into the certificate 11. 

[0091] Although the present invention has been de- 
scribed in detail With reference to preferred embodi- 
ments, persons having ordinary skill in the art will ap- 
preciate that various modifications and different imple- 
mentations may be made without departing from the 
spirit and scope of the invention. 
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1. Method for securing data relating to users of a pub- 
lic key infrastructure who may present certificates 
(11) at an institution (30) in order to initiate transac- 
tions, comprising the steps of 

a) providing cryptographic means to the institu- 
tion (30) which are designed for encrypting and 
decrypting data, 

b) generating relational data based on an 
agreement between a certificate holder and the 
institution (30), 

c) encrypting the relational data by the institu- 
tion (30) with said cryptographic means, 

d) integrating the encrypted relational data into 
the certificate (1 1 ) of said certificate holder and 

e) decrypting said encrypted relational data 
contained in the certificate (11) of said certifi- 
cate holder with said cryptographic means 
whenever a transaction is to be performed 
based on said agreement between the certifi- 
cate holder and the institution (30). 

2. Method accordingto claim 1 comprising the steps of 

a) generating a secret key or a key pair (35, 36) 
which is designed for encrypting and decrypting 
data and which is used and securely stored by 
the institution (30), 

b) generating relational data based on an 
agreement between a certificate holder and the 
institution (30), 

c) encrypting the relational data with the secret 
key or the first key of said key pair (35, 36) of 



d) integrating the encrypted relational data into 
the certificate (1 1 ) of said certificate holder and 

e) decrypting said encrypted relational data 
contained in the certificate (11) of said certifi- 
cate holder by means of the secret key or the 
second key of said key pair (35, 36) of the in- 
stitution (30) whenever a transaction is to be 
performed based on said agreement between 
the certificate holder and the institution (30). 

Method according to claim 1 or 2, comprising the 
steps of binding the relational data securely to the 
corresponding certificate and by combining the en- 
crypted relational data with a certificate identifier, 
such as the hash of the certificate body, which has 
been signed by the certification authority (1 02). 

Method according to claim 3, comprising the steps 
of building a hash of the combination of the encoded 
relational data and the certificate identifier and sign- 
ing the combined data by the institution (30). 

Method according to one of the claims 1 -4, compris- 
ing the steps of sending the encrypted or combined 
and signed relational data to the authority (101, 
102) of the public key infrastructure which has is- 
sued the certificate (11), said authority (101, 102) 
adding the received encrypted relational data to the 
certificate (11) and reissuing said certificate (11). 

Method according to one of the claims 1 -5, compris- 
ing the steps of transferring the reissued certificate 
(11) which contains the encrypted or signed rela- 
tional data to the certificate holder and/or to the in- 
stitution (30) preferably during the session the en- 
crypted or signed relational data was received by 
the authority (101, 102). 

Method according to one of the claims 1 -6, compris- 
ing the steps of securely storing the keys (35, 36) 
of the key pair, which are used for encrypting and 
decrypting relational data, separated from each oth- 
er in different locations or departments of the insti- 
tution (30). 

Method according to one of the claims 1 -6, compris- 
ing the steps of securely storing the secret key, 
which is used for encrypting and decrypting rela- 
tional data, at the institution (30). 

Method according to one of the claims 1 -8, compris- 
ing the steps of comparing the decrypted relational 
data with data stored in a directory (33) of the insti- 
tution (30) in which data of clients and relations be- 
tween the institution (30) and said clients are stored 
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in order to check integrity of said data. 

10. Method according to one of the claims 1-9 compris- 
ing the steps of integrating encrypted or signed re- 
lational data in the certificate individually for more 5 
than one agreement or confirmed information. 

11. Method particularly according to one of the claims 
1-10 for securing data relating to users of a public 
key infrastructure who may present certificates (11 ) 10 
in order to prove information corresponding to said 
data, comprising the steps of 

a) generating relational data based on informa- 
tion related to a certificate holder, said informa- <5 
tion being confirmed by the institution (30) by 

b) securely transferring said relational data to 
the certification authority (1 02) and 

20 

c) integrating the signed relational data into the 
certificate (11 ) of said certificate holder. 

12. Method according to one of the claims 1-11 com- 
prising the steps of generating additional relational 25 
data based on one or more additional certificates, 

the certificate holder has received from other au- 
thorities of the public key infrastructure, and inte- 
grating said additional relational data signed and/or 
encrypted into the certificate (11). so 

13. Method -according to one of the claims 1-12 com- 
prising the steps of storing the certificate (11) in a 
token (1 0) which preferably comprises a biometric 
input device (1). 35 

14. Method according to one of the claims 1-13 using 
an extendable certificate (11) such as a certificate 
specified according to ITU recommendation X.509 
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(54) Method for securing data relating to users of a public-key infrastructure 



(57) The inventive method allows to secure data re- 
lating to users of a public key infrastructure who may 
present certificates (11) at an institution (30) in order to 
initiate transactions. For this purposes the institution 
(30) uses and securely stores a secret key or a key pair 
which is designed for encrypting and decrypting data. 
Based on an agreement between a certificate holder 
and the institution (30), corresponding relational data 
are generated. Then said relational data are encrypted 
with the institution's (30) secret key or the first key of 
said key pair. Subsequently the encrypted relational da- 
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ta are integrated into the certificate (1 1 ) which preferably 
adheres to ITU recommendation X.509 version 3. At a 
later stage, whenever the certificate holder contacts the 
institution (30) in order to initiate a transaction based on 
said agreement between the certificate holder and the 
institution (30), encrypted relational data contained in 
the certificate (11) is decrypted by means of the secret 
key or the second key of said key pair of the institution 
(30). Based on the decrypted relational data, data stored 
in a directory (33) of the institution (30) can be verified 
and the requested transaction be performed. 
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